meta: add initial `GOVERNANCE.md` #5040

thoughtpolice · 2024-12-06T19:51:18Z

After lots of discussion, we've finally achieved a draft of the governance document!

This is a draft, as it is fundamentally incomplete; that will require the election of the initial set of 5 Jujutsu Maintainers, after an open self-nomination period! Stay tuned for more on that.

This is the result of a lot of back and forth, the weekly efforts of the governance working group, currently consisting of:

Martin von Zweigbergk (martinvonz)
Waleed Khan (arxanas)
Emily Shaffer (nasamuffin)
Austin Seipp (thoughtpolice; yours truly)

Many thanks as well to emeritus member Khionu Sybiern, who helped kickstart this whole process.

GOVERNANCE.md

PhilipMetzger · 2024-12-06T20:52:32Z

You forgot to add it to the website and renaming the old temporary governance.

nasamuffin

Seems like a solid start, and I'm glad to see other community members chiming in. Should we push this review more in the Discord starting next week, when people are likely to be back from vacationing?

GOVERNANCE.md

nasamuffin · 2024-12-30T18:48:15Z

GOVERNANCE.md

+performance, code quality, and "style" (fitting in with the project).
+- Participating in design discussions, especially with regards to architecture
+or long-term vision.
+- When necessary, participate in a collective voting process to resolve


I worry that this one doesn't quite fit with the others. Voting on conflicts and decisionmaking is a privilege and a duty of a maintainer, not just a thing that someone typically does before being considered for maintainership, right? It might make more sense to call out the duty of the maintainer in a separate list than the "typical behavior of the maintainer" list here.

GOVERNANCE.md

nasamuffin · 2024-12-30T18:52:01Z

GOVERNANCE.md

+- Forking the project and maintaining your own version
+
+While these are all generally quite valuable, they don't directly contribute to
+the existing community of users where they are at, and on their own do not


Finding this part pretty hard to understand: "contribute to the existing community of users where they are at"

Maybe can you say in comments in way more words what you meant, and we can try to find a concise way to say it more clearly than this together?

GOVERNANCE.md

nasamuffin · 2024-12-30T18:55:08Z

GOVERNANCE.md

+vote.
+
+A Maintainer can be removed by other Maintainers, subject to a vote of at-least
+a 2/3rds majority from the existing Maintainer group (including the vote of the


What's the reason to include the vote of the person nominated for removal? Usually projects explicitly exclude that person's vote (like in Sociocracy) - I'm curious about the rationale for including it, which seems unusual.

IIRC it was somewhat arbitrary. I might have said something vaguely in favor of allowing the person in question to have a say. If it's atypical, then we can adjust it.

I think we also considered what kind of voting thresholds made sense to accommodate the 2/3rds majority. For 5 people, considering whether to include the voted-on Maintainer in their own vote means either —

if including their vote, then 4/5 of the Maintainers are needed to kick them (which is a unanimous vote from everyone else)

if not including their vote, then 3/4 of the remaining Maintainers are needed to kick them (which is 3/5 of all Maintainers, allowing up to one dissenter to be overridden)

Actually, writing that down, I think we had been in favor of letting 3/5 of all Maintainers kick one of the other Maintainers. So this provision as written isn't actually consistent with that scenario, and we should probably change it.

nasamuffin · 2024-12-30T18:56:26Z

GOVERNANCE.md

+
+In the event that a decision is reached before the proposed timeline, said
+proposal can move on and be accepted immediately. In the event no consensus is
+reached, a proposal may be re-submitted later on.


Do we also want to make provision for a proposal that was rejected (not just non-consensus) but where new information comes up later on that makes it worth reevaluating?

To me, it seems like we don't need to legislate that specifically. Maybe we can move the "In the event no consensus is reached [...]" provision into parentheses to make it clear that there's not a specific process for resubmitting proposals, and you can just resubmit proposals in a reasonable way?

nasamuffin · 2025-01-02T19:01:27Z

New update looks good to me, for starters. Only thing I might add is - what's the process for modifying governance.md? Do changes need to go to a maintainer vote through the regular process? Since this is a good start but fairly bare-bones, I think it's worth outlining how we intend to update it later if/when we need to.

GOVERNANCE.md

arxanas · 2025-01-02T20:02:53Z

GOVERNANCE.md

+
+In the event that a decision is reached before the proposed timeline, said
+proposal can move on and be accepted immediately. In the event no consensus is
+reached, a proposal may be re-submitted later on.


To me, it seems like we don't need to legislate that specifically. Maybe we can move the "In the event no consensus is reached [...]" provision into parentheses to make it clear that there's not a specific process for resubmitting proposals, and you can just resubmit proposals in a reasonable way?

arxanas · 2025-01-02T20:08:21Z

GOVERNANCE.md

+vote.
+
+A Maintainer can be removed by other Maintainers, subject to a vote of at-least
+a 2/3rds majority from the existing Maintainer group (including the vote of the


IIRC it was somewhat arbitrary. I might have said something vaguely in favor of allowing the person in question to have a say. If it's atypical, then we can adjust it.

I think we also considered what kind of voting thresholds made sense to accommodate the 2/3rds majority. For 5 people, considering whether to include the voted-on Maintainer in their own vote means either —

if including their vote, then 4/5 of the Maintainers are needed to kick them (which is a unanimous vote from everyone else)

if not including their vote, then 3/4 of the remaining Maintainers are needed to kick them (which is 3/5 of all Maintainers, allowing up to one dissenter to be overridden)

Actually, writing that down, I think we had been in favor of letting 3/5 of all Maintainers kick one of the other Maintainers. So this provision as written isn't actually consistent with that scenario, and we should probably change it.

arxanas · 2025-01-02T20:10:16Z

GOVERNANCE.md

+
+### Maintainers
+
+At the top of the hierarchy are the **Maintainers**. We consider maintainers to


suggestion: I don't think we need to explicitly call out anything "hierarchical", as it seems like somewhat anti-collaborative wording (and, indeed, we added the Contributor role to recognize the valuable contributions of non-Maintainers).

suggestion: I think we should move the actual authority and responsibility up to the top here as the primary definition of a Maintainer, namely that they can conduct votes to resolve conflicts. @nasamuffin already noted below that it didn't belong in the list of Maintainer behaviors.

suggestion: Let's capitalize Maintainer everywhere (assuming that's appropriate?). Likewise for Contributor.

arxanas · 2025-01-02T20:11:35Z

GOVERNANCE.md

+TODO: Pending on the initial process of open nominations, decided by Yuya and
+Martin, more names will be added.
+
+### Contributors


I think it makes sense to write at the top that Contributors are active participants, and that Maintainers are expected to take their feedback into consideration as necessary, but have no formal rights or responsibilities. That should set expectations for how to read the rest of the section.

GOVERNANCE.md

Just shuffling stuff in the cellar. Signed-off-by: Austin Seipp <[email protected]>

This is the result of a lot of back and forth, the weekly efforts of the governance working group, consisting of: - Martin von Zweigbergk (martinvonz) - Waleed Khan (arxanas) - Emily Shaffer (nasamuffin) - Austin Seipp (thoughtpolice; yours truly) Many thanks as well to emeritus member Khionu Sybiern, who helped kickstart this whole process. Signed-off-by: Austin Seipp <[email protected]>

PhilipMetzger · 2025-01-03T15:10:20Z

mkdocs.yml

@@ -131,7 +131,7 @@ nav:
      - 'Code of conduct': 'code-of-conduct.md'
      - 'Design Docs': 'design_docs.md'
      - 'Design Doc Blueprint': 'design_doc_blueprint.md'
-      - 'Temporary Voting for Governance': 'governance/old-temporary-voting.md'
+      - 'Governance': 'governance/GOVERNANCE.md'


Nit: Preserve the old link, as its still somewhat useful.

arxanas · 2025-01-03T19:59:58Z

Only thing I might add is - what's the process for modifying governance.md? Do changes need to go to a maintainer vote through the regular process?

I think basically we expected to use the Decision-Making process for modifying governance.md.

thoughtpolice self-assigned this Dec 6, 2024

martinvonz reviewed Dec 6, 2024

View reviewed changes

nasamuffin reviewed Dec 30, 2024

View reviewed changes

thoughtpolice force-pushed the aseipp/push-xsqsllnzzswk branch from d8a09f7 to e71ca29 Compare January 2, 2025 18:56

thoughtpolice marked this pull request as ready for review January 2, 2025 18:57

PhilipMetzger reviewed Jan 2, 2025

View reviewed changes

GOVERNANCE.md Outdated Show resolved Hide resolved

arxanas reviewed Jan 2, 2025

View reviewed changes

yuja reviewed Jan 3, 2025

View reviewed changes

GOVERNANCE.md Show resolved Hide resolved

GOVERNANCE.md Outdated Show resolved Hide resolved

docs: move old temporary voting procedure

a03002a

Just shuffling stuff in the cellar. Signed-off-by: Austin Seipp <[email protected]>

thoughtpolice force-pushed the aseipp/push-xsqsllnzzswk branch from e71ca29 to e9a2443 Compare January 3, 2025 02:58

thoughtpolice force-pushed the aseipp/push-xsqsllnzzswk branch from e9a2443 to 52fbe51 Compare January 3, 2025 03:01

PhilipMetzger reviewed Jan 3, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

meta: add initial `GOVERNANCE.md` #5040

meta: add initial `GOVERNANCE.md` #5040

thoughtpolice commented Dec 6, 2024 •

edited

Loading

PhilipMetzger commented Dec 6, 2024

nasamuffin left a comment

nasamuffin Dec 30, 2024

nasamuffin Dec 30, 2024

nasamuffin Dec 30, 2024

arxanas Jan 2, 2025

nasamuffin Dec 30, 2024

arxanas Jan 2, 2025

nasamuffin commented Jan 2, 2025

arxanas Jan 2, 2025

arxanas Jan 2, 2025

arxanas Jan 2, 2025 •

edited

Loading

arxanas Jan 2, 2025

PhilipMetzger Jan 3, 2025

arxanas commented Jan 3, 2025


		### Maintainers

		At the top of the hierarchy are the Maintainers. We consider maintainers to

meta: add initial GOVERNANCE.md #5040

Are you sure you want to change the base?

meta: add initial GOVERNANCE.md #5040

Conversation

thoughtpolice commented Dec 6, 2024 • edited Loading

PhilipMetzger commented Dec 6, 2024

nasamuffin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nasamuffin commented Jan 2, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arxanas Jan 2, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arxanas commented Jan 3, 2025

meta: add initial `GOVERNANCE.md` #5040

meta: add initial `GOVERNANCE.md` #5040

thoughtpolice commented Dec 6, 2024 •

edited

Loading

arxanas Jan 2, 2025 •

edited

Loading